Skip to content

Remove SQLitePCLRaw.bundle_green dependency from the package - #18

Open
tomcurran wants to merge 1 commit into
yurkinh:mainfrom
tomcurran:remove-bundle-green-dependency
Open

Remove SQLitePCLRaw.bundle_green dependency from the package#18
tomcurran wants to merge 1 commit into
yurkinh:mainfrom
tomcurran:remove-bundle-green-dependency

Conversation

@tomcurran

Copy link
Copy Markdown

Implements the proposal in #17: the packed SQLiteNetExtensions.Modern nuspec now depends only on sqlite-net-base, leaving the SQLitePCLRaw bundle/provider choice to consumers — which is what the README's Security section already describes as the design intent.

Changes

  • SQLiteNetExtensions.csproj: removed the SQLitePCLRaw.bundle_green 2.1.11 PackageReference (the library never uses SQLitePCL.* APIs directly; SQLitePCLRaw.core still arrives via sqlite-net-base). Added a release-notes bullet.
  • UnitTests.csproj: added an explicit SQLitePCLRaw.bundle_green 2.1.11 reference — the tests need a native provider at runtime and previously got it transitively via the library. This matches what both sample apps already do.
  • README.md: Installation section now states the package ships without a provider and the bundle choice is the consumer's, with a note that other SQLitePCLRaw setups (e.g. config.e_sqlite3 + SourceGear.sqlite3) work too.

Why

  • Consumers with their own provider stack currently get duplicate SQLitePCLRaw.batteries_v2.dll assemblies in the graph, silently resolved by assembly version.
  • Every consumer inherits NU1903 audit warnings from the transitive lib.e_sqlite3 2.1.11 (GHSA-2m69-gcr7-jv3q, no patched 2.x exists), breaking CI with audit gates even when the vulnerable native never ships. This also addresses SQLitePCLRaw.lib.e_sqlite3 has a vulnerable dependency on SQLite #16 at the root.
  • On iOS, bundle_green implies the Apple-OS-provided SQLite — a surprising default the consumer should opt into, not inherit.

Verification

  • dotnet build of the library succeeds.
  • dotnet test UnitTests: 16/16 pass.
  • dotnet pack output nuspec dependencies:
<dependencies>
  <group targetFramework="net10.0">
    <dependency id="sqlite-net-base" version="1.11.272-beta" exclude="Build,Analyzers" />
  </group>
</dependencies>

Note: this is technically breaking for consumers who relied on the implicit bundle — they now need to add a bundle reference themselves (the README already instructed them to). A minor version bump on release seems appropriate; happy to adjust PackageVersion if you tell me the number you want.

🤖 Generated with Claude Code

https://claude.ai/code/session_016q57YbzZxttLptRzv8Nbe5

The library never uses SQLitePCL APIs directly and depends on
sqlite-net-base precisely so consumers control their SQLitePCLRaw
provider. Shipping bundle_green in the package nuspec takes that choice
back: consumers with their own provider stack get duplicate
batteries_v2 assemblies resolved silently by version, and every
consumer inherits NU1903 audit warnings from the transitive
lib.e_sqlite3 2.1.11 (GHSA-2m69-gcr7-jv3q) even when the vulnerable
native never ships.

The packed nuspec now depends only on sqlite-net-base. UnitTests gains
its own explicit bundle_green reference (previously transitive via the
library), matching what both sample apps already do. README updated to
state the bundle choice belongs to the consumer.

Fixes yurkinh#17

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016q57YbzZxttLptRzv8Nbe5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant